HL7 vs FHIR, Explained Simply

HL7 is the old hospital telephone system; FHIR is the newer web-addressable filing cabinet. That is not a perfect comparison, but it is close enough to get us out of the fog without committing architectural vandalism. Health Level Seven (HL7), the standards organization and family of healthcare interoperability standards, gave hospitals a way to move clinical facts between systems long before smartphones, cloud platforms, and modern web application programming interfaces (APIs) made everyone expect data to arrive neatly wrapped, searchable, and somewhat house-trained. Fast Healthcare Interoperability Resources (FHIR), a newer HL7 standard, tries to make healthcare data easier to exchange using web-era ideas: resources, profiles, uniform resource locators (URLs), JavaScript Object Notation (JSON), Extensible Markup Language (XML), and Representational State Transfer (REST), which is the familiar style behind much of the modern web.

The usual question, “HL7 versus FHIR,” is therefore slightly crooked. It sounds like asking whether roads are better than addresses. HL7 version two, the messaging standard that still carries much of the operational bloodstream of hospitals, is mostly about events. A patient was admitted. A lab test was ordered. A result was produced. A medication order changed. A patient was discharged. These events are pushed from one system to another, often through interface engines that filter, transform, route, enrich, delay, retry, and occasionally perform the sort of quiet miracles that never make it into architecture diagrams. FHIR, by contrast, is organized around resources: Patient, Observation, Encounter, MedicationRequest, DiagnosticReport, Condition, Practitioner, Organization. It asks: what thing are we talking about, how is it identified, what attributes does it have, and how may another system request or update it?

That distinction is the first key. HL7 version two commonly says, “Something happened; here is a message about it.” FHIR often says, “Here is a structured representation of a thing; you may ask for it, search it, or exchange it.” One is a train whistle. The other is a shelf label. Hospitals need both. A laboratory information system must tell the electronic health record (EHR), meaning the main digital clinical chart, that a potassium result is back. That is event-driven work, and HL7 version two remains very good at it because it is compact, familiar, deeply embedded, and already wired into thousands of clinical workflows. But a mobile app, analytics platform, care coordination tool, or payer-provider integration service may need to ask for a patient’s current medication list, recent observations, or encounter history. That is where FHIR begins to feel less like a Victorian switchboard and more like a modern library catalog.

The old HL7 version two message looks strange to beginners because it is made of pipe-delimited segments. It feels less like prose than a telegram composed by a committee of caffeinated raccoons. Yet there is a sturdy logic under the bristles. Segments such as Message Header, Patient Identification, Patient Visit, Observation Request, and Observation Result carry specific parts of the clinical event. The message is not meant to be beautiful. It is meant to arrive. It is meant to be parsed. It is meant to tell the receiving system enough to do the next operational thing: create the order, post the result, update the census, notify the clinician, file the document, bill the encounter, or feed the data warehouse.

FHIR looks friendlier because it resembles the web. A Patient resource has recognizable fields. An Observation resource can carry a blood pressure reading, a laboratory value, a body weight, or a smoking status. A DiagnosticReport can gather related observations into something closer to a clinical result package. A Bundle can carry a set of resources together. An Implementation Guide (IG), meaning a formal set of rules for using FHIR in a particular context, can restrict optionality, require certain fields, bind elements to terminology systems, and reduce the otherwise extravagant interpretive freedom that makes healthcare data so lively and so dangerous.

But FHIR’s friendliness can deceive. FHIR is not a universal translator. It does not automatically know whether “active medication” means prescribed, dispensed, administered, patient-reported, reconciled, or merely not discontinued in a screen nobody has opened since the monsoon before last. It does not know whether a diagnosis is billing evidence, clinical judgment, historical residue, risk adjustment scaffolding, or a hurried click made at the end of a clinic day. FHIR improves representation. It does not abolish ambiguity.

This is where many healthcare data projects go wrong. They treat old HL7 as the ugly problem and FHIR as the clean solution. In reality, both are containers. The deeper issue is meaning. Data transport is the act of moving a fact-shaped object from one system to another. Semantic meaning is the question of what that object actually denotes in clinical, operational, temporal, and organizational context. A message may travel perfectly and still mean the wrong thing. A FHIR resource may validate beautifully and still misrepresent reality. The pipes may be clean while the water is philosophical mud.

Take a laboratory result. In HL7 version two, the result arrives as an event message. In FHIR, it may be represented as an Observation, perhaps grouped under a DiagnosticReport. That sounds simple until one asks ordinary hospital questions. Was the specimen collected at the bedside, in the lab, or by an outside facility? Was it corrected later? Was it preliminary, final, amended, canceled, or reflexed into another test? Does the timestamp represent ordering, collection, receipt, performance, verification, posting, or interface arrival? Which code is authoritative: the local laboratory code, Logical Observation Identifiers Names and Codes (LOINC), or a mapped value in the analytics layer? If the same test appears twice, is it a duplicate, a correction, a panel component, or a clinically distinct repeat? These are not small clerical annoyances. They are the difference between data and evidence.

This is why representation failures are so often mislabeled as data quality failures. The data may be faithfully copied from the source system. The source system may be faithfully recording the workflow it was built to support. The interface may be faithfully transmitting what it received. Yet the analytic consumer may call the result “bad data” because it does not behave like the clean clinical variable imagined in a spreadsheet. The failure is not always quality. Often it is category error. A billing diagnosis is being treated as a disease registry assertion. A medication order is being treated as medication exposure. An encounter timestamp is being treated as clinical onset. A discharge summary problem list is being treated as a living ontology of the patient’s body. That is not dirty data. That is a bad map being blamed for not being the territory.

HL7 version two persists because it solves immediate operational problems with astonishing durability. It is not elegant, but neither is a city sewer system, and one should be careful before sneering at the thing that keeps the city from floating away. Hospitals have decades of interfaces, vendor contracts, downstream dependencies, interface engine transformations, local code maps, custom segments, exception handlers, monitoring scripts, and human support routines built around HL7 messages. Replacing that with FHIR is not like replacing a light bulb. It is more like replacing plumbing in a hospital while the surgeons are operating, the cafeteria is open, and the billing department is asking why yesterday’s procedures disappeared.

FHIR matters because it gives healthcare a better shared grammar for many newer use cases. It is more approachable for developers outside traditional healthcare integration. It supports modern API patterns. It can expose data in smaller, more modular pieces. It is more suitable for patient access, app ecosystems, care coordination, payer-provider exchange, and cloud-native data services. It also encourages clearer modeling through profiles and implementation guides. Where HL7 version two often relies on local interface agreements and institutional folklore, FHIR at least offers a more explicit contract.

Yet FHIR also inherits healthcare’s old sins. Optionality can become chaos with a badge. Profiles can multiply until every implementation guide becomes its own small kingdom. Terminology bindings can look rigorous while local practice quietly escapes through extensions. Extensions themselves are both necessary and treacherous: necessary because healthcare reality always exceeds the base model, treacherous because too many extensions turn a standard into a decorated private dialect. FHIR can reduce friction, but it cannot repeal organizational entropy.

The practical architectural question is not, “Should we use HL7 or FHIR?” The better question is, “Which boundary are we crossing, and what kind of truth must survive the crossing?” If the boundary is operational and event-driven, HL7 version two may remain the sensible tool. If the boundary is query-based, patient-facing, ecosystem-facing, or service-oriented, FHIR may be the better fit. If the boundary is analytic, research, quality measurement, or population health, neither standard alone is sufficient. You will need canonical models, terminology governance, provenance, temporal rules, source-system lineage, and a ruthless distinction between what was recorded, what was inferred, what was normalized, and what was merely convenient.

A canonical model, meaning an internal enterprise representation used to reduce chaos across many source systems, can help. But it must not become a fantasy kingdom where all local complexity is ironed flat. A good canonical model preserves provenance. It records source context. It distinguishes raw from normalized data. It supports late-binding transformation, where meaning is resolved closer to the use case when more context is available, instead of early-binding transformation, where source data is prematurely forced into a universal shape and the discarded nuance is never seen again. Early binding feels efficient. It often produces elegant warehouses full of irreversible mistakes.

For example, a healthcare organization may receive HL7 version two messages from laboratories, admission-discharge-transfer systems, radiology systems, and pharmacy systems. It may expose selected data through FHIR APIs. It may also load normalized data into a warehouse or lakehouse for analytics. That architecture is not inherently confused. It becomes confused when leaders pretend each layer means the same thing. The message layer reflects workflow events. The FHIR layer reflects exchangeable resources. The warehouse layer reflects analytic design choices. The clinical source system reflects documentation behavior shaped by reimbursement, regulation, liability, staffing, screen design, and institutional habit. These layers overlap, but they are not identical. Treating them as identical is how dashboards acquire the moral confidence of scripture and the accuracy of gossip.

The deepest difference, then, is not age. HL7 version two is older, but age is not failure. FHIR is newer, but novelty is not truth. The deeper difference is orientation. HL7 version two is optimized around event notification between institutional systems. FHIR is optimized around resource-based exchange in a web-native environment. HL7 version two tends to move data because something happened. FHIR tends to expose data because something may need to be known. Both can be abused. Both can be implemented badly. Both can carry nonsense with impressive punctuality.

For practitioners, the useful path is mixed, sober, and unglamorous. Keep HL7 version two where it works and where replacement would add risk without corresponding value. Use FHIR where APIs, modular access, patient-mediated exchange, app integration, and cross-organization workflows need cleaner contracts. Do not build a FHIR façade over chaos and call it interoperability. Do not flatten local codes into standard terminologies without preserving the original codes and mapping logic. Do not confuse validation with correctness. Do not confuse conformance with comprehension. Above all, do not let a successful transport test convince anyone that meaning has arrived safely.

The simplest explanation is this: HL7 version two helps hospital systems shout events across the corridor; FHIR helps modern systems ask for structured clinical objects by name. The first is still everywhere because hospitals run on events. The second is increasingly important because healthcare now expects data to be discoverable, reusable, patient-accessible, and computable outside the walls where it was born. Neither standard saves us from the central burden of healthcare IT: the patient is real, the workflow is local, the data is partial, and the representation is always a negotiation with loss.

Good architecture begins by admitting that loss. Then it designs around it.